Virtual network interface objects

ABSTRACT

Methods and apparatus for interfaces to manage virtual network interface objects. A system may include resource instances and a network interface virtualization coordinator. Responsive to a record creation request, the coordinator creates an interface records that may include an IP address, subnet information and security properties. The coordinator may, in response to a request to attach the record to a resource instance, enable traffic directed to the IP address to flow to the resource instance. In response to a subsequent detach request, the traffic to the IP address may be disabled at the resource instance. The same interface record may be attached to another resource instance in response to another attach request, enabling traffic directed to the IP address to flow to the second resource instance.

PRIORITY INFORMATION

This application is a continuation of U.S. patent application Ser. No.13/339,985, filed Dec. 29, 2011, now U.S. Pat. No. 8,868,710, whichclaims benefit of priority of U.S. Provisional Application Ser. No.61/561,675 entitled “VIRTUAL NETWORK INTERFACE OBJECTS” filed Nov. 18,2011, the content of which is incorporated by reference herein in theirentirety.

BACKGROUND

Many companies and other organizations operate computer networks thatinterconnect numerous computing systems to support their operations,such as with the computing systems being co-located (e.g., as part of alocal network) or instead located in multiple distinct geographicallocations (e.g., connected via one or more private or publicintermediate networks). For example, data centers housing significantnumbers of interconnected computing systems have become commonplace,such as private data centers that are operated by and on behalf of asingle organization, and public data centers that are operated byentities as businesses to provide computing resources to customers. Somepublic data center operators provide network access, power, and secureinstallation facilities for hardware owned by various customers, whileother public data center operators provide “full service” facilitiesthat also include hardware resources made available for use by theircustomers. However, as the scale and scope of typical data centers hasincreased, the tasks of provisioning, administering, and managing thephysical computing resources have become increasingly complicated.

The advent of virtualization technologies for commodity hardware hasprovided benefits with respect to managing large-scale computingresources for many customers with diverse needs, allowing variouscomputing resources to be efficiently and securely shared by multiplecustomers. For example, virtualization technologies may allow a singlephysical computing machine to be shared among multiple users byproviding each user with one or more virtual machines hosted by thesingle physical computing machine, with each such virtual machine beinga software simulation acting as a distinct logical computing system thatprovides users with the illusion that they are the sole operators andadministrators of a given hardware computing resource, while alsoproviding application isolation and security among the various virtualmachines. Furthermore, some virtualization technologies are capable ofproviding virtual resources that span two or more physical resources,such as a single virtual machine with multiple virtual processors thatspans multiple distinct physical computing systems. As another example,virtualization technologies may allow data storage hardware to be sharedamong multiple users by providing each user with a virtualized datastore which may be distributed across multiple data storage devices,with each such virtualized data store acting as a distinct logical datastore that provides users with the illusion that they are the soleoperators and administrators of the data storage resource.

Operators of data centers that provide different types of virtualizedcomputing, storage, and/or other services usually rely on standardnetworking protocols to receive customer requests and transmit responsesto such requests using commodity network hardware such as various typesof network interface cards (NICs). Despite recent advances invirtualization technology, many networking-related properties of virtualservers are still typically managed at the level of individual physicalnetwork interface cards. As the complexity of the different types ofdynamic networking configuration changes demanded by the customers ofvirtualized services grows, network management at the physical NIC levelmay become more and more cumbersome.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system environment, according to at leastsome embodiments.

FIG. 2 illustrates examples of constituent elements of an interfacerecord, according to at least some embodiments.

FIG. 3 illustrates an operation in which an interface record is attachedto a resource instance, according to some embodiments.

FIG. 4 illustrates an operation in which an interface record is detachedfrom a resource instance, according to some embodiments.

FIG. 5 illustrates an operation in which an interface record is attachedto a different resource instance than the instance to which the recordwas previously attached, according to some embodiments.

FIG. 6 illustrates an operation in which a second interface record isattached to a resource instance, according to some embodiments.

FIG. 7 illustrates an operation in which a resource instance with anattached interface record is moved from one service platform to another,according to some embodiments.

FIGS. 8 a-8 d provide illustrations of a number of example networkconfigurations achievable by attaching interface records to resourceinstances, according to some embodiments.

FIG. 9 is an illustration of a portion of an exemplary web-basedinterface that may be provided by a network interface virtualizationcoordinator, according to at least some embodiments.

FIG. 10 is a flowchart of a method for providing interface recordservices, according to at least some embodiments.

FIG. 11 is a block diagram illustrating an example computer system thatmay be used in some embodiments.

While embodiments are described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that embodiments are not limited to the embodiments ordrawings described. It should be understood, that the drawings anddetailed description thereto are not intended to limit embodiments tothe particular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope as defined by the appended claims. The headings usedherein are for organizational purposes only and are not meant to be usedto limit the scope of the description or the claims. As used throughoutthis application, the word “may” is used in a permissive sense (i.e.,meaning having the potential to), rather than the mandatory sense (i.e.,meaning must). Similarly, the words “include,” “including,” and“includes” mean including, but not limited to.

DETAILED DESCRIPTION OF EMBODIMENTS

Various embodiments of methods and apparatus for managing virtualnetwork interface objects are described. Networks set up by an entitysuch as a company or a public sector organization to provide one or moreservices accessible via the Internet (such as various types ofcloud-based computing or storage) to a distributed set of clients may betermed provider networks in this document. Such a provider network mayinclude numerous data centers hosting various resource pools, such ascollections of physical and virtualized computer servers, storagedevices, networking equipment and the like, needed to implement anddistribute the services offered by the provider.

For a number of different reasons, for example to greatly enhance theflexibility with which different sets of resources may be accessedwithout having to resort to cumbersome security setting modifications,reconfiguring and/or physically moving network interface cards, in someembodiments an operator of a provider network may set up a set ofvirtualization services for network interfaces. Such services may beenabled by a network interface virtualization coordinator (which mayalso be referred to using the abbreviation “NIVC” in this document)responsible for maintaining, and implementing various operations on, aset of interface records to manage networking operations required toaccess various resources of the provider network. In some embodiments,different parts of the functionality of the NIVC may be incorporatedwithin several different co-operating software components and/ordevices, such as modules of hypervisor or operating system softwarerunning on various hardware platforms of the provider network, routersoftware on edge devices, and the like.

In one implementation the provider network may provide customers withnumerous instances of virtualized compute resources and/or storageresources, each of which may require network addressability to allow thecustomers to interact with it. The NIVC in such an implementation mayallow a customer to request that a modifiable and transferable interfacerecord be created, which includes various elements of networkingconfiguration information (such as for example security policies,addressing and routing information) that the customer wishes to set upand then associate and disassociate as desired with various resourceinstances over time. An interface record may in some embodiments includeone or more Internet Protocol (IP) addresses and a subnet identifier fora subnet to which the IP address or addresses belong. In addition,various security-related settings may be included in the interfacerecords, identifying for example which entities or users are allowed toperform the “attach” and “detach” operations described in further detailbelow. The NIVC may create the requested interface record and in oneembodiment store it in a persistent repository or database of interfacerecords.

The customer may in some embodiments request that the NIVC “attach” theinterface record to a resource instance such as a virtualized computeserver or storage server, thereby enabling the resource instance toreceive incoming traffic directed at an IP address of the interfacerecord, and enabling outbound traffic from the resource instance toindicate that it originated at that IP address. The network traffic mayflow over one or more physical network interface cards (NICs) thathappen to be installed at a physical platform on which the virtualizedresource instance may currently be instantiated, but the properties ofthe interface record may be considered to be independent of anyparticular NIC or NICs, and also independent of any particular resourceinstance. At a given point in time, for example, an interface record mayor may not be associated with (i.e., “attached” to) a resource instance.During a period when it is not associated with any resource instance,the interface record may exist in an inactive or quiescent mode withinthe NIVC's repository of interface records, retaining its properties.

In response to a request to “detach” an interface record from a resourceinstance to which it currently is attached, the NIVC may ensure thattraffic directed to the IP address or addresses of the interface recordno longer reaches the resource instance in some embodiments. Thecustomer may also request that the NIVC now attach the interface recordto a different resource instance (such as a different virtualizedcompute server) than the instance to which it was previously attached.This new attachment operation may then result in IP traffic targeted atthe IP address(es) included within the interface record reaching thenewly attached resource instance, using whichever set of physical NICsis appropriate, thus allowing the customer to easily transfer networkconfiguration settings and associated security settings across resourceinstances without dealing with physical NICs directly. Various otheroperations such as modifications of IP addresses associated with a giveninterface record, modifications of security settings, billing-relatedoperations and the like may be supported by the virtual networkinterface coordinator in various embodiments.

Example System Environment

FIG. 1 illustrates an example system environment, according to at leastsome embodiments. The system 100 may include a plurality of resourceinstances 120, e.g., instances 120A, 120B, 120C and 120D of a providernetwork, set up to provide various types of services to clients 148,such as cloud computing services or cloud storage services. Clients 148may in turn implement a variety of services on instances 120, such asweb sites with associated back-end databases, and expose them to theirown customers. A resource instance 120 may for example implement avirtualized service, such as a virtual computing system or a virtualstorage system, that is resident on one or more physical platforms suchas service platforms 150A, 150B, and 150C of FIG. 1. A service platform150 for a resource instance 120 that provides a virtual computing systemmay, for example, include a hardware server with one or more CPUs (aswell as associated memory, storage and networking hardware) and thesoftware (such as a hypervisor and/or elements of an operating system)that implements the virtualization of the computing system. Similarly, aservice platform 150 that provides a virtual storage system may forexample comprise portions or all of one or more hardware storage devices(such as disk arrays or storage appliances) and the associatedprocessing elements and software.

In some embodiments, resource instances 120 may be transferable from oneplatform 150 to another—for example, a virtual computing system mayinitially be brought up on one physical server, and later moved toanother physical server, as desired. Furthermore, multiple resourceinstances may be resident on one service platform 150—for example,resource instances 120B and 120C are shown resident on service platform150B. The physical resources (e.g., CPUs and network cards) of a serviceplatform 150B with multiple resident resource instances 120 may bedistributed using a variety of schemes in different embodiments. In oneembodiment some of the resources may be allocated exclusively to theresource instances—e.g., if the service platform 150B has four CPUs, twoCPUs may be allocated to resource instance 120B, while the other two maybe allocated to resource instance 120C. In another embodiment, thephysical resources may be shared using time slices—for example, all fourCPUs may be usable by either resource instance, with a schedulingmechanism set up to decide how CPU cycles within a given time slice areto be distributed among the instances, depending on their computingdemands. In the embodiment illustrated in FIG. 1, each service platform150 has one or more physical network interface cards (NICs)—serviceplatform 150A has NIC 110A, service platform 150B has NIC 110B, andservice platform 150C has NICs 110C and 110D. The network trafficflowing to and from a resource instance 120 that happens to be residenton a given service platform 150 flows through one or more of the NICs110 of the service platform. In some implementations a single resourceinstance 120 may span multiple hardware service platforms 150, in whichcase any of the NICs 110 available on any of the multiple serviceplatforms 150 may be used. In one embodiment, a resource instance 120may comprise a non-virtualized server, i.e., a resource instance may beimplemented using a conventional operating system running on a barehardware service platform 150 instead of using hypervisor software.

System 100 may include a network interface virtualization coordinator(NIVC) 180 operable to provide a set of virtualization services fornetwork interfaces in the illustrated embodiment. Clients 148 may submitvarious types of requests 153, including requests to create interfacerecords 170, to attach them to resource instances 120, detach them,modify them, query them, and so on; each of these types of operations isdescribed in further detail below. In response to a given request 153,the NIVC 180 may perform various operations that may affect interfacerecords 170 and resource instances 120 on service platforms 150, asindicated by the arrows labeled 157A, 157B, 157C and 157D. For example,the NIVC 180 may, in response to create requests from clients 148,generate interface records such as 170A and 170B that may each contain aset of networking-related properties that can be associated anddisassociated on demand with various resource instances 120. Theinterface records 170 may be generated in a set of in-memory datastructures, and may be stored in a repository 185 in someimplementations, such as a database on persistent storage. An interfacerecord for a network that used the TCP/IP protocols may include, forexample, one or more IP addresses, one or more subnet identifiers of thesubnets that contain the IP address or addresses, and a set of securityproperties described in further detail below. In some implementationsthe interface record 170 may also include one or more other fields suchas various status fields, source and destination address check settings,billing-related information, an identification of a currently associatedresource instance 120, the Media Access Control (MAC) address of aphysical network interface card 110 currently associated with theinterface record, and the like. Interface records for networks employingnetwork protocols other than TCP/IP may include network address-relatedinformation appropriate for the protocol used.

In some embodiments the NIVC 180 may be configured to perform “attach”operations to dynamically associate interface records 170 with resourceinstances 120, and to thereby enable traffic to flow to and from theresource instances 120 in accordance with the networking and securityproperties specified in the interface records 170. In response to anattachment request 153 received from a client 148, for example, in oneimplementation the NIVC 180 may perform some or all of the followingoperations: (a) validate, based on the security information stored inthe specified interface record 170 and/or elsewhere, that the client isauthorized to request the attachment of the interface record with thespecified resource instance 120; (b) verify that the networkinginformation (IP address or addresses, subnet identifier, etc.) of theinterface record is appropriate for activation of network traffic to andfrom the specified resource instance 120 (e.g., the NIVC 180 may checkwhether an IP address is already in use for another instance andtherefore is unavailable); (c) ensure that a physical NIC 110 isoperational and available for use by the resource instance 120 at theservice platform 150 where the resource instance 120 is currentlyresident; (d) initiate or make the necessary configuration changes,e.g., in hypervisor or operating system software running at the serviceplatform 150 and at the appropriate routers, gateways and other networkdevices of the provider network, to allow the specific resource instance120 to begin to send traffic from, and receive traffic at, the IPaddress or addresses specified in the interface record; and (e) makechanges to the interface record 170 and/or repository 185 to reflect theattach operation performed. As part of the configuration changes, new ormodified routing information such as routing table entries may bepropagated to a set of routers, gateways, and the like in someimplementations. In one embodiment the NIVC 180 may ensure that eachresource instance 120 has at least one interface record 170 attached toit whenever the resource instance is activated or brought up.

The NIVC 180 may also be operable to “detach” or disassociate aninterface record 170 from a resource instance 120 to which it iscurrently attached in some embodiments. In response to a detachmentrequest 153 from a client 148, the NIVC 180 in such embodiments mayprohibit further traffic directed to or from the IP address or addressesspecified in the interface record 170 from flowing to or from theresource instance. In order to do so, the NIVC 180 may perform some orall of the following operations: (a) validate, based on the securityinformation stored in the specified interface record 170 and/orelsewhere, that the client is authorized to request the detachment ofthe interface record from the specified resource instance 120; (b)initiate or make the necessary configuration changes, e.g., withinhypervisor or operating system software running at the service platform150 and at the appropriate routers, gateways and other network devices,to prevent network traffic associated with the IP address(es) of theinterface record 170 from flowing to or from the specified resourceinstance 120 and (c) make changes to the interface record 170 and/orrepository 185 to reflect the detach operation performed.

An interface record 170 that was previously attached to a particularresource instance 120, and then detached from that resource instance120, may later be attached to any desired resource instance (either adifferent resource instance, or the same resource instance to which itwas previously attached) by the NIVC 180 at the request of a client insome embodiments. In such embodiments the same IP address may be usedfirst, during one “attachment period”, to send and receive traffic atone resource instance 120A through a particular NIC 110A, and thenduring a subsequent “attachment period”, to send and receive traffic ata different resource instance 120B, potentially through a different NIC110B and/or at a different service platform 150. In addition to allowingclients to map a given IP address to different resource instances 120 atdifferent times, the NIVC 180 may also allow the client to re-use someor all of the security settings associated with an interface record 170,thus substantially reducing the effort and complexity required formaking networking configuration changes. In many embodiments multipleinterface records 170 may be attached to a single resource instance 120,thus allowing multiple IP addresses to be used for the same resourceinstance. In some implementations a single interface record 170 may beattached to multiple resource instances 120 at the same time: forexample, NIVC 180 may be capable of distributing or load-balancingtraffic directed at a single IP address specified in an interface record170 across two or more resource instances 120. Using these capabilitiesof NIVCs 180, a highly flexible mapping of IP addresses, subnets, andnetwork security settings to resource instances 120 may be implementedin various embodiments.

Example Constituent Elements of Interface Records

FIG. 2 illustrates examples of the constituent elements of an interfacerecord 170, according to at least some embodiments. Only a subset of theelements or fields shown in FIG. 2 may be implemented in someimplementations, and not all the implemented fields may have to bepopulated (i.e., some of the fields may be left blank or null). When aninterface record 170 is created, a new interface identifier 201 may becreated for it. In some implementations, a description field 202 may befilled in by the client 148 that requested the interface recordcreation, e.g., “Interface 1 for news web site”. A provider network inwhich the interface record is to be used may comprise a plurality oflogical partitions in some embodiments, and the interface record 170 maycontain logical partition identifier 203 of in such cases. For example,the operator of the provider network may establish a logical partitionfor a particular customer by setting aside a set of service platforms150, a set of network address ranges, other equipment or resources, andnetwork administration capabilities for exclusive use by that customer,effectively providing the customer with its own isolated and privatedata center or centers even though the equipment being used by thecustomer may actually be resident at facilities shared by othercustomers. A logical partition may include resources that aregeographically distributed in some embodiments, thereby granting thecustomer the benefits of access to a virtual private “cloud” ofresources. In some cases the interface record 170 may include a zoneidentifier 204, which may for example indicate a geographical region orset of data centers whose service platforms 150 may be available forattachment to the interface record 170.

Any of several types of network addressing-related fields may beincluded within an interface record 170 in different embodiments. One ormore private IP addresses 205 may be specified for the interface recordin some embodiments; these IP addresses may be used internally forrouting within the provider network, and may not be directly accessiblefrom outside the provider network. One or more public IP addresses 215may also be included in some embodiments; these IP addresses may bevisible outside the provider network, e.g., to various routers of thepublic Internet or peer networks of the provider network. Variousdevices or components, including for example components of NIVC 180, mayimplement any desired network address translation technique ortechniques to translate between public IP addresses 215 and private IPaddresses 205 in various embodiments as needed. One or more subnetidentifiers 225 may be included within an interface record.

The term subnet, as broadly used herein, is a logically visiblesubdivision of a network. In the case of IP networks, the set of logicalor physical devices that belong to a subnet may be addressed with acommon, identical, most-significant bit-group in their IP address. Thisresults in the logical division of an IP address into two fields, anetwork or routing prefix and the “rest” field. The rest field may serveas a specific identifier for the logical or physical device. The routingprefix may be expressed in Classless Inter-Domain Routing (CIDR)notation, which may be written as the first address of a networkfollowed by the bit-length of the prefix, separated by a slash (/)character. For example, 10.1.1.0/24 is the prefix of an InternetProtocol Version 4 network starting at the address 10.1.1.0, having 24bits allocated for the network prefix, and the remaining 8 bits reservedfor device identification. In IPv4 the routing prefix may also specifiedin the form of the subnet mask, which is expressed in quad-dotteddecimal representation like an address. For example, 255.255.255.0 isthe network mask for the 10.1.1.0/24 prefix. Slightly different notationmay be used for IP Version 6 networks and for networks that useprotocols other than the TCP/IP suite. Subnets may be used in generalfor a variety of reasons—for example to provide logical isolationbetween different sets of network-addressable devices, to arrange theresources of a logical partition (such as a virtual private cloud) intohierarchies for easier administration, and so on. A subnet identifier225 included within an interface record 170 may comprise, in someimplementations, a string that may in turn include or encode the CIDRrepresentation for the subnet—e.g., “subnet-df543fda-10.1.1.0/24”. Inone embodiment an identification of a Domain Name Server (DNS) may beincluded in the interface record 170 as well.

In some embodiments the interface record 170 may includesecurity-related properties 235. Some provider networks may allow usersto specify rules, including for example firewall-related rules, for thetypes of incoming and/or outgoing traffic allowed at resource instances120 to which an interface record 170 may be attached; such rules may betermed “security groups” and identified via security group(s) fields245. Various port and protocol restrictions may be enforced using suchrules, and multiple rules may be associated with each interface record.For example, a user may use security groups to ensure that only HTTP andHTTPs outgoing or incoming traffic is allowed, to limit the set of TCPor UDP (User Datagram Protocol) ports to which traffic is permitted, tofilter incoming and outgoing traffic according to various policies, andso on. In some implementations an attacher list 247 may be specified,indicating which users or entities are allowed to request attachments ofthe interface record 170 to resource instances 120. In some cases aseparate detacher list may be used to specify which entities can detachthe interface record 170, while in other cases a single list such asattacher list 247 may be used to identify authorized attachers anddetachers. The set of users or entities that are allowed to set ormodify IP addresses (e.g., public IP addresses 215 and/or private IPaddresses 205) of the interface record 170 may be provided in IP addresssetter list 249, and the set of users or entities that own (or canmodify various other fields of) the interface record 170 may bespecified in owner/modifier field 253 in some embodiments. For example,an owner/modifier identified in field 253 may be permitted to change theattacher list 247 or the IP address setter list in some implementations,thus changing the set of entities permitted to attach or detach theinterface record or modify its IP address(es). While the term “list” hasbeen used for fields 247, 249, and 253, logical data structures otherthan lists (such as arrays, hash tables, sets and the like) may be usedto represent the groups of entities given various security privileges,roles and/or capabilities in various embodiments.

In some embodiments, users may be allowed to “terminate” resourceinstances 120. For example, a client 148 may set up virtual computeserver resource instances 120, attach interface records 170 to theinstances, run a desired set of computations on the instances, and thenissue a request to terminate the instances when the desired computationsare complete (thus indicating that the resource instances 120 are nolonger required). In such embodiments, a “DeleteOnTerminate” setting 251may be used to specify what happens to attached interface records 170when a resource instance 120 is terminated. If DeleteOnTerminate is setto “true” for an interface record 170 attached to the resource instance120 being terminated, the NIVC 180 may delete the interface record 170(e.g., the record may be removed from repository 185). IfDeleteOnTerminate is set to “false”, the NIVC 180 may retain theinterface record 170, so that for example it may be attached again tosome other resource instance. In one embodiment, when an interfacerecord 170 is attached to a resource instance 120, an attachment recordseparate from the interface record may be created to represent thatrelationship, and the DeleteOnTerminate property may be associated withthe attachment record instead of or in addition to being associated withthe interface record. In such an embodiment, the interface record 170may include a reference or pointer to the attachment record or recordsfor each of the attachments in which the interface record is currentlyinvolved, and different values of “DeleteOnTerminate” may be set foreach attachment record. In such an environment, an instance record 170that happens to be unattached to any resource instances 120 may not havea “DeleteOnTerminate” property associated with it as long as it remainsunattached. By persisting interface records independently of resourceinstances in this way, the overhead of setting up varioussecurity-related and other properties each time a new instance isactivated may be reduced for clients 248.

In one embodiment, the interface record 170 may contain routing-relatedinformation such as an indication 265 of whether a source and/ordestination check is to be performed for network packets transmitted toa resource instance 120 to which the interface record 170 is attached.If the source/destination check setting is set to “false” or “off”,routing decisions may be made based on a packet's source and destinationIP addresses, e.g., the packet may be forwarded from one subnet toanother; and if the setting is “true” or “on”, the resource instance maynot perform routing in some embodiments. Thus the source/destinationfield 265 may be used in some embodiments to control whether a resourceinstance to which the interface record is attached performs routing orgateway functions on packets for which it is not the final destination,or whether it ignores such packets. Other types of routing-relatedinformation, such as routing table entries, may also or instead beincluded in interface records 170 in other embodiments. Billing-relatedinformation 267 may be included in some implementations, identifying forexample the entity or user to be billed for network traffic associatedwith the interface record 170. In some implementations customers may bebilled at least partially based on the number of instance records 170they create, independently of how many of the instance records areattached to resource instances; in other implementations billing mayinclude both recurring charges (e.g., based on the number of instancerecords and/or the number of instance records attached) andnon-recurring charges (e.g., based on traffic flow measurements).

The interface status field 268 may be used to indicate a current stateof the interface record 170—e.g., whether the interface record is“available”, “disabled”, or “in-repair”. Similarly, the attachmentstatus field 269 may be used to indicate whether the interface record170 is currently attached, detached or in the process of being attachedor detached in some embodiments. In one implementation, as describedabove, a record of an attachment (separate from interface record 170)may be created at the time the corresponding attachment operation isperformed, and an identifier or identifiers of the current attachmentsof the interface record 170 may be stored in attachment id field 271.Identifiers of the resource instance or instances 120 to which theinterface record 170 is currently attached may be stored in attached-toinstance field 273, and the user or entity that requested the attachmentmay be identified via attachment owner field 275 in some embodiments. Inone embodiment, a list of identifiers of the NIC or NICs 110 currentlyusable for traffic directed to/from the IP addresses of interface record170 may be maintained, e.g., in the form of a MAC address(es) field 277.In some implementations, monitoring information 279, such as statisticsabout the amount of traffic flowing to or from the IP addresses of theinterface record, may also be retained with the interface record. Otherfields not shown in FIG. 2 may be included in interface records 170 invarious embodiments. In some embodiments, clients may associate tags,such as a virtual local area network (VLAN) tag formatted in accordancewith a VLAN standard (such as the 802.1Q standard) with interfacerecords 170 to implement network isolation. In such embodiments such atag may also be stored in, or referenced from, the interface record 170.

In one embodiment, some of the fields shown in FIG. 2 may be replaced byreferences or pointers to other objects. For example, securityinformation for an interface record 170 may be stored in a separatesecurity object, and the interface record 170 may store a reference tothe security object. Similarly, each attachment of a resource instance120 to an interface record 170 may be represented by an attachmentobject, and the interface record may point or refer to the appropriateattachment object in some implementations.

Attachment, Detachment, and Instance Move Operations

FIGS. 3-7 illustrate examples of several types of operations supportedby NIVC 180 in various embodiments. FIG. 3 illustrates an operation inwhich an interface record 170 is attached to a resource instance 120,according to some embodiments. An attachment request 301 may be sent bya client 148 to NIVC 180, identifying the interface record 170A and theresource instance 120A to which the interface record is to be attached.In FIG. 3, the notation “++” (as in “170A++120A”) for request 301indicates that the request is an attachment request. On receiving therequest, NIVC 180 may verify that the requesting client is authorized torequest the attachment and that the addressing and other information inthe interface record is valid, and then initiate the necessaryconfiguration changes to enable traffic to flow to and from the resourceinstance 120A in accordance with the details specified in the interfacerecord 170A. The operations performed by NIVC 180 in response to theattachment request 301 are indicated in FIG. 3 by the arrow labeled 311and the attachment indicator 321. As noted earlier, a number ofconfiguration changes may have to be made and/or propagated, e.g., atthe hypervisor or operating system of the platform 150A where theresource instance 120A is resident, and at various networking devicessuch as routers and gateways of a provider network being used. Theinterface record 170A itself may be modified in some embodiments, e.g.,by changing the values of various constituent elements such as theinterface status 268, attachment status 269, attachment ID 271,attached-to instance 273, attachment owner 275, and/or MAC address field277. In the illustrated example, the MAC address field 277 of interfacerecord may be set to the MAC address of NIC 110, the NIC usable byresource instance 120A as shown by the dashed lines surrounding the NIC.

Interface records 170 may be attached to resource instances 120 at manydifferent stages of a resource instance's lifecycle in one embodiment.For example, a resource instance 120 may be in a running statesubsequent to booting (and may already be servicing requests received atan IP address of another interface record to which it is alreadyattached) when a particular interface record is attached to it. In someembodiments NIVC 180 may permit interface records 170 to be attached toa resource instance 120 even if the resource instance 120 is notcurrently up or running—for example, when the resource instance isstopped or suspended, or is in the process of being activated. In such acase, for example, a network interface record may be attached to theresource instance before the resource instance is activated or booted,and even before the service platform 150 on which it is to be brought upis selected. If insufficient information is available at the time theattachment operation is requested—for example if the MAC address of theNIC or NICs to be used are not yet known—NIVC 180 may leave some of thefields of the interface record 170A blank or null until the values dobecome available. In some embodiments, NIVC 180 may generate and/orstore records or data structures for each attachment—e.g., an objectwith an associated attachment identifier may be stored in repository 185or some other database, identifying the resource instance 120A, theinterface record 170A, and other information pertaining to theattachment, such as the time at which the attachment operation wasinitiated or completed. In some embodiments a given client 148 may havea set or pool of interface records 170 available for use for theclient's resource instances 120, and the client may simply request thatNIVC 180 choose an available interface record 170 from the pool ofinterface records to attach to a specified resource instance 120.

The IP addresses used for the resource instance 120 attached to theinterface record 170 may be modifiable in some embodiments after theattachment operation is completed. For example, if a user or entityidentified as being authorized to change an IP address such as a publicIP address 215 or a private IP address 205 sends an IP addressmodification request to NIVC 180, the NIVC may make the necessaryconfiguration changes needed to make the requested change effective. Forexample, on receiving the IP address modification request for aninterface record 170, the NIVC may first determine which resourceinstances 120 (if any) are currently attached to the interface record170, and then enable traffic directed at the changed IP address to reachthose resource instance(s), and make the needed changes in the interfacerecord 170 itself. In one embodiment, one or more of the IP addressesassociated with the interface record 170, such as either a public IPaddress 215 or a private IP address 205, may be selected by NIVC 180 onbehalf of the client from a set of IP addresses allocated for theclient.

FIG. 4 illustrates an operation in which an interface record 170 isdetached from a resource instance 120, according to some embodiments. Adetachment request 401 may be sent by a client 148 to NIVC 180,identifying the interface record 170A and the resource instance 120Afrom which the interface record is to be detached. In FIG. 3, thenotation “−−” (as in “170A−−120A”) for request 401 indicates that therequest is a detachment request. On receiving the request, NIVC 180 mayin some implementations first verify that the specified interface record170A is in fact currently attached to the resource instance 120A. If theinterface record 170A is not attached to the resource instance 120A, theNIVC 180 may either send an error message back to the requesting client148, or in some implementations simply log and/or ignore the request. Ifthe interface record 170A is attached to the resource instance 120A, theNIVC 180 may check that the requesting client is authorized to requestthe detachment, and then initiate the necessary configuration changes todisable traffic to flow to and from the resource instance 120A inaccordance with the details specified in the interface record 170A. Theoperations performed by NIVC 180 in response to the detachment request301 are indicated in FIG. 4 by the arrow labeled 411 and the “X” acrossthe attachment indicator 321. The detachment configuration changes mayin effect simply undo the attachment configuration changes describedearlier. The interface record 170A itself may be modified in someembodiments, e.g., by changing the values of various constituentelements such as the interface status 268, attachment status 269,attachment ID 271, attached-to instance 273, attachment owner 275,and/or MAC address field 277. In the illustrated example, the MACaddress field 277 of interface record may be set to null upondetachment.

In some embodiments, a detachment request 401 may not explicitlyidentify the interface record 170A that is to be detached—instead, therequesting client may simply indicate that any attached interfacerecords 170A should be detached from the specified resource instance120. In such a case, NIVC 180 may be operable to first discover, e.g.,by looking up the information in repository 185, which interface records170 should be detached from the resource instance 120 specified, andthen initiate the detachment operations. Such a request (to detach allattached interface records 170) may, for example, be generated when aresource instance is being shut down, disabled, terminated or discarded.In some implementations, if the “DeleteOnTerminate” field is set to truefor an interface record 170 and an attached resource instance 120 isbeing terminated, the interface record itself may be deleted fromrepository 185; otherwise, if “DeleteOnTerminate” is set to false, theinterface record may be retained in the repository together with itsproperties, for possible reuse later. As noted above, in someembodiments the “DeleteOnTerminate” property may be associated withattachment records to which the interface record may refer, instead ofbeing associated with the interface records themselves. In someimplementations a detachment request 401 may not necessarily indicate aresource instance 120A, and may only indicate that the specifiedinterface record 170A should be detached from whichever resourceinstance 120 (if any) to which it happens to be attached.

FIG. 5 illustrates an operation in which an interface record 170A thatwas previously attached to one resource instance 120A, and thendetached, is attached to a different resource instance 120C, accordingto some embodiments. An attachment request 501 may be sent by a client148 to NIVC 180, identifying the interface record 170A and the resourceinstance 120C to which the interface record is to be attached. In FIG.5, as in FIG. 3, the notation “++” (as in “170A++120C”) indicates thatthe request is an attachment request. On receiving the request, NIVC 180may perform functions analogous to those described earlier inconjunction with the description of FIG. 3, this time attaching theinterface record 170C to resource instance 120C, resident on a differentservice platform (150B) than the previously-attached instance 120A, andusing a different NIC (NIC 110B, as indicated by the dashed lines inFIG. 5). The operations performed by NIVC 180 in response to theattachment request 501 are indicated in FIG. 5 by the arrow labeled 511and the attachment indicator 521. The use of interface records 170 thatcan be dynamically attached to different resource instances 120 (and candynamically change the NICs 110 used) allows NIVC 180 to provide clients148 with significant flexibility in the network architectures used fortheir applications, and with opportunities to collaborate acrossbusiness boundaries, as will be described below in the section on usecases. For example, in one environment resource instances 120 may havebeen set up to handle web service requests of a particular applicationfrom customers. In such an environment, simply by detaching interfacerecord 170A from one resource instance 120A as shown in FIG. 4, and thenattaching the interface record with a different resource instance 120C,while keeping the IP address(es) of the interface record 170A unchanged,a workload of incoming web service requests that were previously beinghandled at resource instance 120A can now be handled at resourceinstance 120C. This may allow clients 148 to provide enhancedavailability, e.g., if resource instance 120A experiences an outage orfailure, or an easy-to-use mechanism for deploying an enhanced versionof the web service application, e.g., if resource instance 120C has theenhanced version.

In some embodiments NIVC 180 may allow multiple interface records 170 tobe attached to the same resource instance 120. FIG. 6 is an illustrationof one such embodiment, where a second interface record 170B is attachedto a resource instance 120C that already has an interface record 170Aattached to it. In response to attachment request 601, NIVC 180 mayperform operations analogous to those described for the attachmentrequest 301 of FIG. 3, such that network traffic to and from resourceinstance 120C eventually flows in accordance with the properties of bothinterface records 170A and 170B. The operations performed by NIVC 180 inresponse to the attachment request 601 are indicated in FIG. 6 by thearrow labeled 611 and the additional attachment indicator 621. In theexample illustrated in FIG. 6, a single NIC 110B is used to handle thetraffic for both attached interface records 170A and 170B. In someembodiments, the mapping between interface records 170 and physical NICs110 may be flexible: that is, traffic flowing through a given NIC 110may correspond to any number of interface records 170, and traffic for agiven interface record 170 may flow through multiple physical NICs 110.

In some implementations resource instances 120 may be transferableacross service platforms 150 while retaining their attached interfacerecords 170 and at least some of the corresponding networking-relatedproperties. FIG. 7 illustrates an operation in which a resource instance120A with an attached interface record 170A (as shown previously in FIG.3) is moved from one service platform 150A to resource instance 150C,according to at least some embodiments. In FIG. 7, a client 148 sends a“move instance” request 701 to an instance manager 780 of system 100,indicating that the resource instance 120A that was so far resident onservice platform 150A should now be made resident on service platform150C. The notation “→” (as in “120A→150C”) for request 701 indicatesthat the request is a move request. On receiving the request, instancemanager 780, together with NIVC 180, may perform the tasks needed toimplement the requested move. For example, the move request 701 may bevalidated to ensure that the requester has the right permissions, theresource instance 120A may then be suspended or brought into a state inwhich incoming requests are temporarily queued. The resource instance120A may then be brought up or enabled on the service platform 150C, andconfiguration changes needed to make traffic directed at the IPaddress(es) of the attached interface 170A flow through an appropriateNIC or NICs 110 at the service platform 150C may then be initiated. Inthe example shown in FIG. 7, traffic to and from the resource instance120A is routed through NIC 110C after the instance has moved (the MACaddress field of the interface record 170A may be modified to reflectthis in some embodiments). In this way, the networking properties of aresource instance (i.e., the networking properties of its attachedinterface records) may be made substantially independent of the actualnetworking hardware used. Although a separate instance manager 780 isshown in FIG. 8, the functions of moving resource instances may bemanaged together with the interface virtualization functions in someembodiments, i.e., the same software and/or hardware entities maysupport resource instance administration operations and interface recordmanagement operations as well.

Example Use Cases

The ability to dynamically attach and detach one or more interfacerecords 170 with specified IP addresses and subnets to resourceinstances 120, enabled by the functionality described above, allowscustomers to easily set up several different useful types of networkconfigurations. FIGS. 8 a-8 d provide illustrations of a number of suchexample network configurations achievable, according to someembodiments.

The networking configurations illustrated in FIGS. 8 a-8 d show threedifferent organizational or hierarchical levels for a provider networkthat may contain resource instances 120: the logical partition level,the subnet level, and the interface record level. The operator of such aprovider network may allow a given customer (such as a business ororganization that wishes to utilize virtual computing and/or virtualstorage services supported by the provider network) to set up one ormore logical partitions dedicated for use by that customer. A logicalpartition may, for example, comprise a relatively large set of serviceplatforms 150 and a relatively large number of IP addresses that may beusable for various resource instances 120 that may be brought up onthose service platforms as needed by the customer, and the customer maybe provided network administration capabilities for that set ofresources. In some embodiments, for example, the set of IP addresses ofa logical partition may be specified in CIDR notation as a “/16” blocksuch as “10.1.0.0/16”, which indicates that up to 65,536 IP addressesmay be usable for that logical partition. Logical partitions may betermed “virtual private clouds” in some embodiments. A logical partitionmay have one or more gateways set up for it in some implementations,such as Internet gateways or virtual private network (VPN) gateways. Inaddition, in some implementations a default DNS server may be set up foreach logical partition, and one or more subnets and routing tableentries may also be set up when the logical partition is set up. Forexample, in one implementation when a customer requests that a logicalpartition with a “/16” block be set up, the customer may be required tospecify the CIDR specification for at least one “/24” subnet that is tobe set up within the logical partition as well. A “/24” subnet, e.g.,“10.1.1.0/24”, includes 256 IP addresses. The customer on whose behalfthe logical partition is set up may be allowed to perform a wide varietyof network administration tasks as desired in some embodiments, such assetting up subnets of various sizes, and creating, attaching anddetaching interface records 170 as needed. Different logical partitionsand subnets may be set up to achieve various levels of logicalisolation: for example, a customer may wish to isolate softwaredevelopment build-related network traffic from corporate e-mail networktraffic, and may set up an appropriate hierarchy of logical partitionsand subnets to do so. In one embodiment, the CIDR specifications mayrefer to private IP addresses for interface records 170 (stored forexample in fields 205 shown in FIG. 2), while public IP addresses(stored in fields 215) may be selected in accordance with otherpolicies. Identifiers for subnets (field 225 of FIG. 2) and logicalpartitions (field 203) may be stored within the interface records insome embodiments. In some embodiments some or all of the addressinginformation (logical partition identifier, subnet identifier, privateand/or public IP addresses) of an interface record may be dynamicallymodifiable after the creation of the interface record 170.

Use Case Scenario 1: Multiple IP Addresses within a Single Subnet

FIG. 8 a illustrates a simple networking configuration in which twointerface records 170A and 170B are associated with a single resourceinstance 120A within a subnet 811A, according to one embodiment. Theinterface record 170A is shown with example IP address x.x.x.9 and theinterface record 170B is shown with example IP address x.x.x.10. (Thenotation “x.x.x” common to the two addresses means that the first threedot-separated elements of the two IPV4 addresses are identical in thiscase, for example the two addresses may be 11.2.3.9 and 11.2.3.10.) Byattaching multiple interface records 170 as shown, as many different IPaddresses as desired may be associated with the same resource instancein some embodiments. This may be useful, for example, to isolate trafficfor different applications or application instances by IP address. Inone environment, for example, several different web sites may be set upon a single resource instance 120, each with its own IP address. Inanother embodiment, a customer may have multiple web servers serving thesame underlying content set up on a single resource instance 120, andmay wish to associate each web server with a different IP address.

Use Case Scenario 2: Attaching to Multiple Subnets in a Single LogicalPartition

FIG. 8 b illustrates a configuration in which two interface records 170Aand 170C from different subnets are associated with a single resourceinstance 120A, according to one embodiment. The interface record 170A isshown with example IP address x.x.0.9 within subnet 811A and theinterface record 170C is shown with IP address x.x.1.10 within adifferent subnet 811B. This kind of configuration may be useful, forexample, in an environment where network management traffic flowsthrough one subnet 811A while application data traffic flows throughanother subnet 811B, with each subnet having different securityproperties. In one such case, a subnet 811A for network managementtraffic may have stricter security rules and access controls than asubnet 811B used for application data. In another example, a resourceinstance 120 attached to multiple subnets 811 may also be configurableto perform various network security functions. For example, if trafficfrom a first subnet 811A has to be routed to a second subnet 811Bthrough the resource instance 120, the resource instance may implement afirewall, serve as an anti-virus gateway, perform intrusion detectionand/or other types of network traffic analysis, filtering, ormonitoring, and so on.

Configurations similar to that shown in FIG. 8 b may also be used todynamically and efficiently move a resource instance 120 from one subnetto another in some embodiments. For example, a customer may have set upan application server instance on a resource instance 120A attached tointerface record 170A within a subnet 811A dedicated to a softwaredevelopment environment, and deployed an updated version of anapplication on the application server instance. If the customer desiresto start quality assurance (QA) testing on the updated version, and theQA test environment is in a subnet 811B isolated from the developmentsubnet 811A, the following steps may be taken. First, a second interfacerecord 170C from subnet 811B may be attached to the resource instance120A. Then the interface record 170A may be detached from the resourceinstance 120A, thus enabling the testing to be done in the desired QAsubnet alone without having to deploy the updated version of theapplication on a different resource instance. Similarly, applicationsmay be moved easily through other development lifecycle stagetransitions, such as from a QA environment to a production environment,and so on.

In one environment, a customer may wish to isolate a set of front-endweb servers or other resources accessible from external networks (i.e.,devices outside the provider network containing resource instances 120)from a set of back-end servers such as database servers that may storesensitive data, such that direct network access to the back-end serversfrom external networks is to be prevented. In such a case, the resourceinstance 120A of FIG. 8 b may use subnet 811A for front-end traffic andsubnet 811B for back-end traffic in some embodiments. Thus requests forweb services may be received via subnet 811A at a web server running onresource instance 120A, and the corresponding back-end requests neededto fulfill those requests may be sent to the back-end servers in subnet811B. Responses from the back-end servers may be received from subnet811B and transmitted back to the requesters via subnet 811A.

In some implementations, an instance 120 that is attached to multipleinterface records 170 in different subnets may also be used as a router.For example, if a packet received at the resource instance has a sourceIP address reachable from the resource instance through one subnet, anda destination IP address reachable through another subnet, and theappropriate configuration settings needed are set (e.g., if routingtable entries are set up appropriately), the instance may route thepacket to the destination address via the second subnet.

Use Case Scenario 3: Attaching to Multiple Logical Partitions of theSame Customer

FIG. 8 c illustrates a configuration in which two interface records 170Aand 170D from different logical partitions 801A and 801B set up for thesame customer (Customer A) are associated with a single resourceinstance 120A, according to one embodiment. The interface record 170A isshown with example IP address 10.0.0.9 within subnet 811A of logicalpartition 801A and the interface record 170D is shown with IP address172.16.1.10 within a subnet 811B of a different logical partition 801B.This kind of configuration may be useful for several purposes. The twological partitions 801A and 801B may have been set up for any of avariety of reasons on behalf of Customer A—e.g., to isolate traffic ofCustomer A's private intranet from traffic directed to a de-militarizedzone (DMZ) network exposed by Customer A to their own customers. In suchan environment, the resource instance 120A of FIG. 8 c may be configuredto perform inter-partition routing, for example. In some embodiments thecustomer may wish to have the services provided by resource instance120A accessible from devices in two logical partitions, which may alsobe enabled by using a configuration similar to that of FIG. 8 c.

Of course, some of the other capabilities supported by NIVC 180discussed in use cases 1 and 2 above may also be extended across logicalpartition boundaries using the type of configuration illustrated in FIG.8 c. For example multiple IP addresses may be provided for a givenresource instance 120 in two different CIDR /16 address ranges, resourceinstances may be moved across logical partitions, and so on, in variousembodiments. A resource instance 120A may also provide proxy servicesacross logical partitions 801, or be used to implement a managementnetwork that is in a separate logical partition from a data network insome embodiments.

Use Case Scenario 4: Attaching to Logical Partitions of DifferentCustomers

NIVC 180 may be able to provide a number of bridging services acrosslogical partitions set up for different customers in some embodiments.FIG. 8 d illustrates a configuration in which two interface records 170Aand 170E from different logical partitions 801A and 801B set up forrespective customers (partition 801A for Customer A, and partition 801Bfor Customer B) are associated with a single resource instance 120A,according to one embodiment.

The functionality illustrated in FIG. 8 d may enable a number ofdifferent collaborative scenarios. In one example, Customer A andCustomer B may be collaborating on a project. Customer A may havedeployed a content server application on a resource instance 120A intheir logical partition 801A. Customer B may wish to access that contentserver application, but neither company may want to expose this serverto the public Internet. Instead, Customer B may create an interfacerecord 170E in their own logical partition 801B and set permissions onthat interface record 170E allowing Customer A to attach to it. CustomerA may attach interface record 170E to the resource instance 120A runningthe content server in Customer A's logical partition 801A. Thus, bothcustomers may securely access the content server without having to makeextensive changes. In addition, Customer A may, using the securityproperties of interface record 170E, ensure that only HTTP and HTTPSports are available to Customer B in some implementations, or may limitaccess from Customer B's logical partition in other ways as desired.

In a second scenario where peering between customers may be enabled,Customers A and B may be collaborating on a number of projects and maylike to have private access to each other's logical partitions. CustomerA may launch a gateway application (such as a firewall or router) onresource instance 120A and Customer B may create an interface record170E in one such embodiment. The gateway application owner Customer Amay attach the interface record 170E to the resource instance 120A, sothat both logical partitions are connected via the dual-homed resourceinstance 120A running the gateway application. This scenario may placesome constraints on the IP address ranges of the two customers' logicalpartitions—e.g., if they have overlapping IP addresses some form ofnetwork address translation may be required in some implementations. Insome environments the resource instance 120A may be hosted on adedicated networking appliance (e.g., a router appliance or a firewallappliance).

Cross-partition attachment capabilities may also be used for providingtechnical support capabilities in some embodiments. In one suchscenario, Customer A may be using an application from Vendor X atresource instance 120A, where Vendor X is also a customer of theoperator of system 100. Customer A may have encountered a problem withthe application and may like to receive “hands-on” support from VendorX. Customer A may contact Vendor X, and Vendor X may create an interfacerecord 170E in their own logical partition and give Customer Apermission to attach. Customer A may attach their resource instance 120Ato Vendor X's interface record 170E so that, for example, Vendor X mayuse a secure shell (SSH) or the remote desktop protocol (RDP) to accessthe troubled application and perform troubleshooting as needed. Suchsupport may be supported without using an Internet gateway or virtualprivate network gateway to access Customer A's logical partition.Furthermore, Customer A may in some embodiments modify the egress policy(e.g., using security properties of interface record 170E) to preventany traffic from being transmitted from the resource instance 120A toVendor X's logical partition 801B. This may prevents Vendor X frominadvertently or maliciously accessing other resources in Customer A'slogical partition 801A.

Managed service providers (MSPs) may also be able to take advantage ofthe cross-partition attach capabilities in some embodiments. An MSP(Customer A) may host applications in its own logical partition (e.g.,801A) and attach to interface records 170 in their customers' logicalpartitions (e.g., partition 801B of MSP Customer B), thus providing theMSP customers with endpoints in their own partitions to access the MSPapplication. The MSP may maintain control of the resource instances(e.g., 120A) where their applications run, while the MSP customers maybe able to access the MSP applications via IP addresses in the MSPcustomers' network space. MSP applications may include any of a varietyof different types of services, such as customer relationship management(CRM), content management, collaboration, databases and the like.

In addition to the examples illustrated in FIGS. 8 a-8 d, thecapabilities of NIVC 180 may also enable other types of services invarious embodiments. For example, when and if a first resource instance120 attached to an interface record 170 fails or has an outage, a formof high availability (HA) may be implemented by attaching the interfacerecord 170 to a second resource instance capable of providing similarservices as the first resource instance. In embodiments where system 100supports a variety of services, such as a relational database service,map-reduce or other distributed or parallel computing services,deployment services or load balancing services, a resource instance 120that attaches to multiple customer logical partitions may be used toimplement administration and control services for the various services.Such administration services may be referred to as “control plane”capabilities, as distinguished from “data planes” capabilities used fortransmitting non-administrative application data or user data.

Example Web Interface

In some embodiments NIVC 180 may be operable to implement one or moreinterfaces that define and support some or all of the interfacerecord-related services described above. For example, one or moreapplication programming interfaces (APIs) may be implemented, or varioustypes of graphical user interfaces (GUIs) or command-line interfaces maybe provided in various implementations. FIG. 9 is an illustration of aportion of an exemplary web-based interface that may be provided by NIVC180, according to at least some embodiments.

Web page 900 of FIG. 9 includes several form fields that a client 148may fill out to provide details of an interface record creation request.In area 903 of web page 900, a friendly greeting and overview messagemay be provided. Form field 904 may allow the client to specify a nameand a description for the interface record. In embodiments where logicalpartitions are implemented, a form field 905 may be provided to allowthe client to specify a logical partition for the requested interfacerecord 170. In some implementations, a set of identifiers of the logicalpartitions from which the client 148 is authorized to select one may bemade available automatically, e.g., via a drop-down menu, and/or field905 may be pre-populated with a default logical partition identifierthat the client may modify. Form field 909 may be used to specify asubnet identifier for the interface record. One or more IP addresses(including private and/or public IP addresses) may be specified usingform field 917. Form field 921 may be available for specifying varioussecurity properties, such as security groups, lists of entities allowedto attach the interface record, and the like. Field 925 may beoptionally used to identify a resource instance 120 to which theinterface record is to be attached. As in the case of field 905, severalof the other fields on web page 900 may also be pre-populated withdefault values in some implementations, and/or a selection of allowedchoices may be provided via a drop-down menu or a similar mechanism.Submit button 931 may be used to submit the interface record creationrequest.

NIVC 180 may in one implementation generate values for some or allfields that may be left unfilled by the requesting client 148. In someimplementations employing a web-based interface, several different webpages may be employed during the process of creating an interfacerecord. As the client fills out one form entry, the NIVC 180 may be ableto customize or narrow the set of options available for subsequent formentries. In some implementations the submission of form data via aninterface like web page 900 may result in an invocation of one or moreAPI calls that may be supported by NIVC 180.

Interfaces similar to that illustrated in FIG. 9 for creating aninterface record 170 may also be provided for the other types ofoperations supported by NIVC 180 in various embodiments, such asattachment operations, detachment operations, delete operations, IPaddress change operations, and the like. In some embodiments clients 148may be allowed to submit queries to, for example, determine the statusof interface records 170, identify the interface records 170 attached toa given resource instance 120, list all the interface records set up bythe client 148 in a given subnet or logical partition, and so on.

Methods for Interface Record Operations

FIG. 10 is a flowchart of a method for providing interface recordoperations, according to at least some embodiments. As shown in element1800 in the flowchart, an interface virtualization service may beimplemented, e.g., in the form of an NIVC 180. In some implementations,the service may be implemented by a combination of software and/orhardware components, for example via components of hypervisor software,operating system software, or routing software that runs on variousdevices within a provider network. As shown in element 1805, one elementof the service may be configured to wait for interface virtualizationrequests, which may for example be received via a web-based interfacesimilar to that shown in FIG. 10.

Depending on the specific type of request received, the appropriate setof actions may be taken in response. For example, if a request to createa new interface record is received (element 1810 of FIG. 10), such arecord 170 may be instantiated and optionally stored in a repository(element 1815). If a request to attach an existing interface record isreceived (element 1820), traffic flow directed to or from the IP addressor addresses specified for the interface record may be enabled at theresource instance 120 to which the attachment is requested (element1825). If a detach request is received (element 1830), traffic to andfrom the IP address(es) of the interface record may be disabled (element1835) at the resource instance to which the interface record wasattached. If a request to delete an interface record is received(element 1840), the record may be deleted, e.g., from repository 185(element 1845).

On receiving a request to modify an interface record (e.g., to change anIP address) (element 1850), the record may be modified as requested, andany needed configuration changes may be initiated (element 1855). Onreceiving an interface record query (e.g., to determine the status of aninterface record or records) (element 1860), the response to the querymay be generated and provided (element 1865). In each case, theappropriate authorization and security checks may be performed prior toperforming the requested action or actions. In some implementations,some types of interface-record operations may be implemented asidempotent operations, e.g., if a first request to change an IP addressto A.B.C.D is received, followed by a second request that requests thesame change, the second request may have no effect. If an unexpected,unsupported, unauthorized or otherwise invalid request is received, anerror message may be generated in some implementations. After respondingto a given request, the service may then wait for the next interfacevirtualization request. In some implementations, portions of thefunctionality shown in FIG. 10 may be implemented in parallel, e.g.,more than one request may be handled at one time. In someimplementations several requests may be combined—e.g., a single requestto both create and attach an instance record may be supported.

Illustrative Computer System

In at least some embodiments, a server that implements a portion or allof one or more of the technologies described herein, including thetechniques to provide various services and operations related tointerface records 170, may include a general-purpose computer systemthat includes or is configured to access one or more computer-accessiblemedia, such as computer system 2000 illustrated in FIG. 11. In theillustrated embodiment, computer system 2000 includes one or moreprocessors 2010 coupled to a system memory 2020 via an input/output(I/O) interface 2030. Computer system 2000 further includes a networkinterface 2040 coupled to I/O interface 2030.

In various embodiments, computer system 2000 may be a uniprocessorsystem including one processor 2010, or a multiprocessor systemincluding several processors 2010 (e.g., two, four, eight, or anothersuitable number). Processors 2010 may be any suitable processors capableof executing instructions. For example, in various embodiments,processors 2010 may be general-purpose or embedded processorsimplementing any of a variety of instruction set architectures (ISAs),such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitableISA. In multiprocessor systems, each of processors 2010 may commonly,but not necessarily, implement the same ISA.

System memory 2020 may be configured to store instructions and dataaccessible by processor(s) 2010. In various embodiments, system memory2020 may be implemented using any suitable memory technology, such asstatic random access memory (SRAM), synchronous dynamic RAM (SDRAM),nonvolatile/Flash-type memory, or any other type of memory. In theillustrated embodiment, program instructions and data implementing oneor more desired functions, such as those methods, techniques, and datadescribed above, are shown stored within system memory 2020 as code 2025and data 2026.

In one embodiment, I/O interface 2030 may be configured to coordinateI/O traffic between processor 2010, system memory 2020, and anyperipheral devices in the device, including network interface 2040 orother peripheral interfaces. In some embodiments, I/O interface 2030 mayperform any necessary protocol, timing or other data transformations toconvert data signals from one component (e.g., system memory 2020) intoa format suitable for use by another component (e.g., processor 2010).In some embodiments, I/O interface 2030 may include support for devicesattached through various types of peripheral buses, such as a variant ofthe Peripheral Component Interconnect (PCI) bus standard or theUniversal Serial Bus (USB) standard, for example. In some embodiments,the function of I/O interface 2030 may be split into two or moreseparate components, such as a north bridge and a south bridge, forexample. Also, in some embodiments some or all of the functionality ofI/O interface 2030, such as an interface to system memory 2020, may beincorporated directly into processor 2010.

Network interface 2040 may be configured to allow data to be exchangedbetween computer system 2000 and other devices 2060 attached to anetwork or networks 2050, such as other computer systems or devices asillustrated in FIGS. 1 through 10, for example. In various embodiments,network interface 2040 may support communication via any suitable wiredor wireless general data networks, such as types of Ethernet network,for example. Additionally, network interface 2040 may supportcommunication via telecommunications/telephony networks such as analogvoice networks or digital fiber communications networks, via storagearea networks such as Fibre Channel SANs, or via any other suitable typeof network and/or protocol.

In some embodiments, system memory 2020 may be one embodiment of acomputer-accessible medium configured to store program instructions anddata as described above for FIGS. 1 through 10 for implementingembodiments of methods and apparatus for virtual network interfacerecords. However, in other embodiments, program instructions and/or datamay be received, sent or stored upon different types ofcomputer-accessible media. Generally speaking, a computer-accessiblemedium may include non-transitory storage media or memory media such asmagnetic or optical media, e.g., disk or DVD/CD coupled to computersystem 2000 via I/O interface 2030. A non-transitory computer-accessiblestorage medium may also include any volatile or non-volatile media suchas RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc, that may beincluded in some embodiments of computer system 2000 as system memory2020 or another type of memory. Further, a computer-accessible mediummay include transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network and/or a wireless link, such as may be implemented vianetwork interface 2040. Portions or all of multiple computer systemssuch as that illustrated in FIG. 11 may be used to implement thedescribed functionality in various embodiments; for example, softwarecomponents running on a variety of different devices and servers maycollaborate to provide the functionality.

CONCLUSION

Various embodiments may further include receiving, sending or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Generally speaking, acomputer-accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.),ROM, etc, as well as transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as network and/or a wireless link.

The various methods as illustrated in the Figures and described hereinrepresent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. The orderof method may be changed, and various elements may be added, reordered,combined, omitted, modified, etc.

Various modifications and changes may be made as would be obvious to aperson skilled in the art having the benefit of this disclosure. It isintended to embrace all such modifications and changes and, accordingly,the above description to be regarded in an illustrative rather than arestrictive sense.

What is claimed is:
 1. A system, comprising: a plurality of resourceinstances including a first resource instance and a second resourceinstance; and a network interface virtualization coordinator; whereinthe network interface virtualization coordinator is operable to: inresponse to an interface record creation request, generate an interfacerecord comprising a first Internet Protocol (IP) address, a subnetidentifier of a first subnet containing the first IP address, and afirst set of security properties, and store the interface record in arepository; in response to a first attachment request to attach theinterface record to the first resource instance, enable the firstresource instance to receive traffic targeted at the first IP addressthrough a first network interface card in accordance with the first setof security properties; and in response to a detachment request todetach the interface record from the first resource instance, preventthe first resource instance from receiving traffic targeted at the firstIP address.
 2. The system as recited in claim 1, wherein the networkinterface virtualization coordinator is further operable to: in responseto a second interface record creation request, generate a secondinterface record comprising a second IP address, and store the secondinterface record in the repository; and in response to a new attachmentrequest to attach the second interface record to the first resourceinstance, enable the first resource instance to receive traffic targetedat the second IP address.
 3. The system as recited in claim 2, whereinthe second IP address is part of a second subnet, and wherein the secondinterface record comprises a subnet identifier of the second subnet. 4.The system as recited in claim 3, wherein the network interfacevirtualization coordinator is further operable to: receive, at the firstresource instance, a network packet from a source IP address, whereinthe source IP address is reachable from the first resource instance viathe first subnet, and wherein the network packet has a destination IPaddress reachable from the first resource instance via the secondsubnet; and route the network packet to the destination IP address viathe second subnet.
 5. The system as recited in claim 1, wherein theinterface record comprises one or more additional IP addresses, andwherein, in response to the first attachment request to attach theinterface record to the first resource instance, the network interfacevirtualization coordinator is further operable to enable the firstresource instance to receive traffic targeted at the one or moreadditional IP addresses.
 6. The system as recited in claim 1, whereinthe network interface virtualization coordinator is further operable to:in response to an IP address modification request comprising a new IPaddress, modify the interface record to include the new IP address;identify a currently-attached resource instance of the plurality ofresource instances to which the interface record is attached; and enablethe currently-attached resource instance to receive traffic directed atthe new IP address.
 7. A method, comprising: in response to an interfacerecord creation request, generating an interface record comprising an IPaddress and a subnet identifier of a first subnet containing the firstIP address, and storing the interface record in a persistent repository;in response to a first attachment request to attach the interface recordto a first resource instance of a plurality of resource instances,enabling the first resource instance to receive traffic targeted at thefirst IP address; and in response to a detachment request to detach theinterface record from the first resource instance, preventing the firstresource instance from receiving traffic targeted at the first IPaddress, and retaining the interface record in the persistentrepository.
 8. The method as recited in claim 7, further comprising: inresponse to a second interface record creation request, generating asecond interface record comprising a second IP address; and in responseto a second attachment request to attach the second interface record tothe first resource instance, enabling the first resource instance toreceive traffic targeted at the second IP address.
 9. The method asrecited in claim 8, wherein the second IP address is part of a secondsubnet, and wherein the second interface record comprises a subnetidentifier of the second subnet.
 10. The method as recited in claim 9,further comprising: receiving, at the first resource instance, a networkpacket from a source IP address, wherein the source IP address isreachable from the first resource instance via the first subnet, andwherein the network packet has a destination IP address reachable fromthe first resource instance via the second subnet; and routing thenetwork packet to the destination IP address via the second subnet. 11.The method as recited in claim 9, further comprising: in response to anIP address modification request comprising a new IP address, modifyingthe interface record to include the new IP address; identifying acurrently-attached resource instance of the plurality of resourceinstances to which the interface record is attached; and enabling thecurrently-attached resource instance to receive traffic directed at thenew IP address.
 12. The method as recited in claim 9, wherein the firstsubnet is part of a first logical partition of a network with a firstCommon Internet Domain Routing (CIDR) address prefix, and the secondsubnet is part of a second logical partition of the network with asecond CIDR address prefix.
 13. The method as recited in claim 7,wherein the interface record comprises a set of security propertiesincluding a first authorization entry identifying one or more entitiesauthorized to submit an attachment request.
 14. The method as recited inclaim 13, wherein the set of security properties includes a secondauthorization entry identifying one or more entities authorized tomodify the first authorization entry.
 15. A non-transitorycomputer-accessible storage medium storing program instructionscomputer-executable to implement: in response to an interface recordcreation request, generating an interface record comprising an IPaddress and a subnet identifier of a first subnet containing the firstIP address, and storing the interface record in a persistent repository;and in response to a first attachment request to attach the interfacerecord to a first resource instance of a plurality of resourceinstances, wherein the first resource instance is in a running statesubsequent to its booting up, enabling traffic targeted at the first IPaddress to be received at the first resource instance.
 16. Thenon-transitory computer-accessible storage medium as recited in claim15, wherein the program instructions are computer-executable toimplement: in response to a second interface record creation request,generating a second interface record comprising a second IP address; andin response to a second attachment request to attach the secondinterface record to the first resource instance, enabling the firstresource instance to receive traffic targeted at the second IP address.17. The non-transitory computer-accessible storage medium as recited inclaim 16, wherein the second IP address is part of a second subnet, andwherein the second interface record comprises a subnet identifier of thesecond subnet.
 18. The non-transitory computer-accessible storage mediumas recited in claim 17, wherein the program instructions arecomputer-executable to implement: receiving, at the first resourceinstance, a network packet from a source IP address, wherein the sourceIP address is accessible from the first resource instance via the firstsubnet, and wherein the network packet has a destination IP addressaccessible from the first resource instance via the second subnet; androuting the network packet to the destination IP address via the secondsubnet.
 19. The non-transitory computer-accessible storage medium asrecited in claim 15, wherein the interface record comprises a set ofsecurity properties including an authorization entry identifying one ormore entities authorized to modify the IP address.
 20. Thenon-transitory computer-accessible storage medium as recited in claim15, wherein the interface record comprises a set of security propertiesincluding an authorization entry identifying at least one of: a portrestriction for incoming traffic, a protocol restriction for incomingtraffic, a protocol restriction for outgoing traffic, or a protocolrestriction for outgoing traffic.
 21. The non-transitorycomputer-accessible storage medium as recited in claim 15, wherein theprogram instructions are computer-executable to implement: in responseto an IP address modification request comprising a new IP address,modifying the interface record to include the new IP address;identifying a currently-attached resource instance of the plurality ofresource instances to which the interface record is attached; andenabling the currently-attached resource instance to receive trafficdirected at the new IP address.
 22. The non-transitorycomputer-accessible storage medium as recited in claim 17, wherein thefirst subnet is a data subnet designated for transmission of clientapplication data, and the second subnet is a management subnetdesignated for transmission of network administration data.
 23. Thenon-transitory computer-accessible storage medium as recited in claim16, wherein the first IP address is part of a first network logicalpartition maintained on behalf of a first customer, and wherein thesecond IP address is part of a second network logical partitionmaintained on behalf of a second customer.